home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄22⁄91 / 3031-Re MA3 opinion,for w-Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.9 KB  |  70 lines  |  [TEXT/GEOL]
  1. Item    4199861                         20-Feb-91        11:21
  2.  
  3. From:   LSR@APPLE.COM@INTERNET#         Gateway to Internet/BITNET/UUCP
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. INTERNET# Document Id: <12176@goofy.Apple.COM>
  8.  
  9. ------------------------------------------------------------------------------
  10.  
  11. Sub:    Re: MA3 opinion,for what its w
  12.  
  13. If you use AppleLink 6.0, you win! The Reply button works for gatewayed E-mail.
  14. Otherwise, copy & paste this: lsr@Apple.COM@INTERNET#
  15.  
  16. From: lsr@Apple.COM (Larry Rosenstein)
  17. Subject: Re: MA3 opinion,for what its worth
  18. References: <667070461.3039537@AppleLink.Apple.COM>
  19. Lines: 43
  20. Organization: Apple Computer, Inc.
  21. Newsgroups: apple.mac.app
  22. Path: apple!lsr
  23. To: macapp.tech$@applelink.apple.com
  24.  
  25.  
  26. In article <667070461.3039537@AppleLink.Apple.COM> SATORI@AppleLink.Apple.COM
  27.  (Satori SW, Hugh Rogovy,PRT) writes:
  28. >
  29. >I would think that that any competent OP programmer who puts forth a small
  30. >amount of effort would be able to make the syntax transition to C++ (use the
  31.  
  32. I agree.  While it's true that you can write some convoluted expressions and
  33. declarations, these are the exception, rather than the rule.
  34.  
  35. >isn't the issue here.  What we(I) really need a guarantee that MacApp is going
  36. >to become design-stable (or painlessly updatable) someday.  We wrote an app in
  37.  
  38. It's hard to know what's the right thing to do in this case.
  39.  
  40. The standard Mac Toolbox doesn't have the "luxury" of making major changes,
  41. because it is shared between applications.  Applications continue to work on
  42. new systems/ROMs.  On the other hand, adding new features is very difficult;
  43. today's Macintosh suffers because of design decisions made in 1984.
  44.  
  45. MacApp is linked with every application, so there is more freedom to make
  46. changes.  Developers can choose to stick with their existing version rather
  47. than update.  (You lose new features and bug fixes, but you gain stability.)
  48.  
  49. When the number of MacApp users was small, the feeling we got was that
  50. improvements were more important than stability.  Perhaps that's no longer
  51. true.
  52.  
  53. >code can many times be a hindrance) costs us money.  It is true that source
  54. >code for the toolbox is not available, but the toolbox wasn't followed by a
  55. >42-page bug report, either.  I don't mean that as a slight to the MA team,
  56. >they
  57.  
  58. I'm sure that the Toolbox has as many bugs as the Toolbox.  But the Toolbox
  59. bug descriptions are spread out over many different Tech Notes (if they are
  60. written down at all).  The reason MacApp has a 42-page bug report has more
  61. to do with the MacApp community (both inside and outside of Apple) than with
  62. the quality of MacApp or with the issue of source vs. no-source.
  63.  
  64. Larry
  65. --
  66.                  Larry Rosenstein,  Object Specialist
  67.  Apple Computer, Inc.  20525 Mariani Ave, MS 3-PK  Cupertino, CA 95014
  68.             AppleLink:Rosenstein1    domain:lsr@Apple.COM
  69.                 UUCP:{sun,voder,nsc,decwrl}!apple!lsr
  70.